Conversation
Original commit message:
unix: treat futimens() as best-effort in copyfile
futimens() may fail with EPERM on CIFS/SMB shares that do not
support setting timestamps. Since preserving timestamps during
copyfile is best-effort, ignore the return value unconditionally.
Refs: libuv/libuv#4396
Fixes: nodejs#56248
|
Review requested:
|
|
Failures look unlikely to be related, would someone mind re-running the jobs? 🙏 |
|
Looks like different failures again. Not sure what's going on here. The first one ( The second ( Mac is still pending macos15-x64. |
|
Still having very strange issues, one target reported all the tests as "missing". The other looks like a completely different async flake this time. Is the strategy that we keep running this until the tests are fixed upstream or the CI is more stable? Assistance would be much appreciated. |
Cherry-pick libuv/libuv@439a54b to fix
uv_fs_copyfile()failing withEPERMon CIFS/SMB mounts. Timestamp preservation is now best-effort, matching the existing treatment offchown()in the same function. I'm also the author of the libuv fix.This is a regression introduced by the libuv 1.49.0 update (Node.js 22.12.0 via #55114), which added timestamp preservation to
uv_fs_copyfile(). Since then,fs.copyFile()/fs.copyFileSync()have failed withEPERMon CIFS/SMB mounts on Linux.The buggy block is the same on
v22.x-stagingandv24.x-staging(both on libuv 1.51.0), solts-watch-v22.xandlts-watch-v24.xare good candidates once this matures.Fixes: #56248
Refs: libuv/libuv#5053
Refs: libuv/libuv#4396